Games of Daze/Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso/x2ftp/msdos/libs/advent1b/advman.doc

Text File | 1993-10-11 | 99.1 KB | 2,851 lines

READ THE FOLLOWING INFORMATION CAREFULLY.

The Advent system (with the exception of PLAYA.EXE) is
Shareware.  This means that you may distribute Advent to
other potential users, according to the normal Shareware
rules:

1.   No charge should be made for Advent.

2.   If a charge is made it must be stated clearly that
     the charge has been made to cover copying and media
     costs, and that the Advent system has not been
     purchased.

3.   All copies must include all the program,
     documentation and example files.

Beware of viruses.  It is a sensible precaution to check
any disk for viruses before you give it away.  You should
also check new floppy disks before using them on your
machine.

I can accept no responsibility for any damage to
hardware, software or data which comes about by the use
of any copy or version of the Advent system.

Users of Advent should register their copy by sending £20
to:

S. Morphet,
49 Meadowfield Road,
Stocksfield,
Northumberland,
ENGLAND.
NE43 7PZ.

Payment should be made out to 'Mr. S. Morphet.'

If possible, please send the revision number of your
version of Advent.  This number is obtained by typing:

ADVENT /V

at the DOS command line.

As a registered user you will be eligible for support and
advice on Advent, a printed manual, and update
information.

The PLAYA.EXE program is used to play a finished game,
and as such should be distributed with any game that the
user creates with Advent, and subsequently offers for
sale, or for distribution as Shareware, in the Public
Domain, etc.  For this reason the PLAYA.EXE program is
released as Public Domain software.  Again, no charge
other than a copying fee must be made for PLAYA.EXE, and
users of PLAYA.EXE are not required to register it.
__________________________________________________________
__________________________________________________________


ADVENT USER MANUAL - PART 1.

ADVENTURE GAMES.

Nothing beats a good adventure of an evening.  Wouldn't
you rather be fighting your way through jungle
undergrowth, devising cunning means of crossing swollen
rivers, swinging intrepidly across snake filled pits, and
dodging the poison yo-yos wielded so expertly by tree
dwelling rabbits, instead of reading this?  Perhaps it
all sounds a bit much?  Too dangerous perhaps?  Or maybe
you can't afford the plane ticket?  Never mind, a
computer adventure game allows you to explore, solve
puzzles, or even do battle with rabbits if you should so
wish, all without leaving the comfort of your VDU!

Most people have played an adventure game at least once,
they even appear occasionally on magazine 'cover disks',
but how many people have ever designed and written their
own?  The Advent software allows you to create
complicated adventure games with absolutely no prior
computer programming knowledge.  Simply give the computer
a list of the places and objects in the game, and tell it
the rules!

If you do not have at least some experience of adventure
games it would probably be a good idea to try a couple
before you start to write your own.  This will give you a
good idea of the way that they work, the sorts of puzzles
encountered etc...

When you have written your adventure game you may
distribute it according to the rules set out in Appendix 5.


INSTALLING AND RUNNING ADVENT.

Advent V1.0 is usually supplied on one 3╜" (720K) disk,
this may differ according to the source of the disk.  Some
shareware libraries may be able to supply the system
(compressed) on a 5╝" (360K) disk.

Whatever the disk format, you may find that the system has
been compressed.  In this case the shareware library should
provide instructions for decompressing them.

Advent should run on any I.B.M. P.C. or compatible computer
with 512K RAM.  The software adapts to the graphics adapter
in use, working in 80 column text mode, which is supported
by all P.C.s.  Monochrome and colour screens are supported.

Four program (.EXE) files are provided on your Advent disk,
or in a compressed file.  These are ADVENT.EXE, the
database editor, PLAYA.EXE the interpreter, and the utility
programs ADVLOCK.EXE and ADVPACK.EXE.

You will use ADVENT to create your adventure game, and
PLAYA to play it when complete.  ADVENT also makes
calls to PLAYA in order for you to test the adventure during
development.

Advent requires no special installation.  First you should
make a copy of the ADVENT disk, and put the original
away in a safe place.  You can then use ADVENT without any
fear of corrupting the programs.

The disk may contain a README file containing late-breaking
news that is not contained in this manual.  You should read this
file before using Advent.

If you use a hard disk drive, you should copy the all ADVENT
files into a single sub-directory of your hard disk and this will
considerably increase the speed of the system.

Advent can be used from floppy disks.  On a system with 3╜"
disks, all the program files can be stored on and run from a
single disk.  Data can be stored on another disk and Advent
will prompt for disk changes if required.

On a system with low density 5╝" (360K) disks, the programs
ADVENT.EXE and PLAYA.EXE should be copied onto one
disk, and the programs ADVLOCK.EXE and ADVPACK.EXE
onto another.  The system is then run from the first disk, and
he second disk is inserted when ADVPACK or ADVLOCK
are to be run from the DOS prompt.  Data can be stored on a
further disk as described above.


THE ADVENT SYSTEM.

As has already been mentioned, there are four programs
that comprise the ADVENT system.  The program ADVENT.EXE
is the database editor.  A database is the name given to
the two files that comprise any game you create, these
files are stored on disk.  One, with the file extension
.DAT is called the data file, and contains text data and
the `rules' of the game.  The second has the extension
.IDX and is used as an index to the data file, allowing
the appropriate data to be found rapidly.

The database editor program guides you through the
creation and development of such a database with the
minimum effort.

The second program on the programs disk is called
PLAYA.EXE, this is the Interpreter, the program which
interprets the database, and allows you to play the games
that you have created.  PLAYA.EXE is also used if you
wish to test your adventure game during development.
Running PLAYA.EXE from the ADVENT database editor
environment allows you to use additional facilities to
control and monitor the way in which the system is
working.

The last two programs on the disk are less important, but
help you to produce top quality games suitable for
distribution.

ADVLOCK.EXE allows you to apply a password lock to your
database.  This does not prevent users from playing the
game, but means that another user with the Advent editor
cannot make unauthorised changes to your database.  See
the section in Part 3 of this manual 'Other programs
supplied with Advent.'

ADVPACK.EXE is a program which removes any inefficiency
in the storage of data in your data files.  As you edit
data, gaps may be left in the data file, perhaps wasting
a tiny bit of space each time.  ADVPACK removes these
spaces, but does not compress real data, which means you
can still edit your database.  The program also reorders
database entries as explained in Part 3 'Other programs
supplied with Advent.'


INTRODUCTION TO THE ADVENT DATABASE EDITOR

RUNNING ADVENT.

To run Advent, make sure you are in the directory
containing the Advent files, type ADVENT and press RETURN
on the DOS command line.  This will load the database
editor program into memory.


THE MAIN MENU.

All the menus in Advent are operated using the cursor
keys to move the highlight bar to the desired option,
then press RETURN to make a selection.

The Advent database consists of a variety of texts and
tables of information.  Each type is accessed via the
main menu:


VOCABULARY.

This option allows you to control the words which the
computer understands, in other words, its vocabulary.
Every word is allocated a number by which the interpreter
recognises the word.  You may also specify SYNONYMS, ie,
different words which have exactly the same meaning to
the computer.


MESSAGE TEXT.

When an incident occurs in the adventure, the player
needs to be told about it.  Message texts allow this to
happen.  Typical messages may be,

"You throw the boomerang away, but it swiftly returns,
try as you might you just can't get rid of the thing."

or,

"The telephone rings."


LOCATION TEXT.

Here you are able to enter and amend the texts which
describe the locations in the adventure.  Every location
could be thought of as a room, upon entering the room a
message is displayed describing it, for example:

"You find yourself in the bathroom.  A large hairy spider
peers at you out of the bath, and looks ready to pounce."

or,

"You are inside the sea slug.  It's digestive workings
look alarmingly hungry.  The walls are decorated with
cool pink slime."

Obviously, whilst the location texts will often refer to
rooms, they need not do.  A street, tree, country, cavern
or slug interior are all equally valid.


THE MOVEMENT TABLE.

In the movement table you describe the connections
between locations, or if you like, the doors between
different rooms.  A movement table entry exists for every
location, and tells the interpreter where the player will
end up if certain commands, usually directions such as
NORTH or SOUTH, are entered whilst at that location.


OBJECT TEXT.

Every adventure has objects in it, things that the player
can manipulate, move around, and use to solve problems.
A torch, for example is a handy thing to be carrying when
the lights go out!  The objects are each identified by a
short text, the OBJECT TEXT.


OBJECT START LOCATION.

When the game starts the objects will be distributed
around the various locations.  The object start location
gives the location number of the location where each
object is situated at the beginning of the game.


THE EVENT AND STATUS TABLES.

The event table, together with the status table, defines
the rules by which the game is played.  In the event
table, players commands, usually in the form VERB-NOUN,
are associated with a series of actions, which will be
executed if certain conditions are met at the time when
the command is entered.  The status table works in a
similar way, but the execution of the actions depends
only upon the conditions which must be met, and not on
the commands entered by the player.


SYSTEM MESSAGES.

These are similar to MESSAGE TEXTS but are displayed by
the interpreter during game play, for example to prompt
the player for input, to tell them that it is dark, or to
warn the player if the interpreter doesn't understand its
instructions.  Each message can be changed to suit your
preferences but should always retain the same meaning.


OBJECT WORDS.

The AUTO* actions in the event table can save you a lot
of typing.  They require objects to be associated with a
word from the vocabulary, and that word is set using this
option.


TEST ADVENTURE.

This option allows you to test your adventure from within
the editor environment, by making a call to the
interpreter program PLAYA.EXE.  The testing process uses
exactly the same program as will be used when you
actually play the game, so you can be sure that whatever
happens during testing will be what happens in the game
proper.  In the test mode you also have the option to
display the states of up to forty of the four hundred
flags used by Advent.  This diagnostic feature allows the
easy correction (or debugging) of your game when things
go wrong.


EXIT ADVENT.

Advent saves your data as you work.  Data is stored on
disk as it is entered, and the index data is updated
regularly.  This means that you need not worry about
saving your data, however the EXIT option should be
considered the only safe way to leave the Advent
environment as it ensures that all your data is saved,
and then does some extra tidying up.  Indeed, Advent
actively discourages you from exiting Advent other than
through this option.  When choosing the exit option you
are also given the opportunity to load a different
adventure database into Advent.


THE ADVENT TEXT EDITOR.

The Advent database editor is designed for the easy entry
of information, much of which will be in the form of
text, for example, location descriptions, messages, and
descriptions of objects.

The text editor mode is used to enter text into Advent,
or to make changes to text that has been entered
previously.
The text editor screen appears automatically when text
input is required, for example, to enter a message or
location description.  It is also used in the event,
status and movement table editor modes to insert or edit
entries.

The text editor is basic, but sufficient.  Text is
entered simply by typing it at the keyboard, and it is
inserted into your text at the current cursor position.

To make changes to your text, use the cursor keys to move
the cursor to any position within the text.  You can also
use the HOME and END keys to move straight to the
beginning or end of the current line, that is, column one
or column eighty.  Typed characters always appear at the
current cursor position.

Text can be deleted using either the DELETE key, which
deletes the character under the cursor, or with BACKSPACE
which deletes the character immediately behind the
cursor.

To overwrite existing text press the INSERT key once, the
area at the bottom of the screen now shows OVERTYPE ON.
Any text you type will overwrite what already exists.
Insert can be turned back on again by pressing INSERT
once again.  Note that overtype is set to OFF every time
you enter the text editor.

The Advent text editor is not a word processor, and has
to be used slightly differently.  You will maybe find it
peculiar at first, but it soon becomes easier:

It is possible for a word to overlap two lines on the
screen, i.e. text is not 'word-wrapped' and the text must
be padded with spaces or a RETURN to prevent this.

Pressing the RETURN key starts a new line by filling the
current one with spaces.  Because of this, some care
needs to be taken when working with text.  Entering text
behind a RETURN will cause the whole text to shuffle
forwards, and the RETURN may cease to line up with the
edge of the screen.  For this reason it is recommended
that you set insert to OFF when working on text that
contains many RETURNs.

When using RETURN in your texts, the two delete functions
Shift-F9 and Shift-F10 may prove useful.  These functions
delete all characters between the cursor and the
beginning or end of the line respectively.  The function
Alt-F7 is used to completely clear the text.  These key
combinations are intentionally non-intuitive to help
prevent accidental erasure of your work.  If the current
editor mode permits their use, they will be displayed at
the bottom of the screen to jog your memory.

When you have finished in the text editor mode, press the
ESC key to return to the menu.

NOTE:  Character graphics can be entered by holding down
the ALT key and typing the extended ASCII code number of
the character required on the NUMERIC KEYPAD.
__________________________________________________________
__________________________________________________________


ADVENT USER MANUAL - PART 2.

YOUR FIRST ADVENT ADVENTURE.

An Advent game is essentially a series of instructions
which define the way the interpreter behaves during a
game.  You simply tell Advent what the instructions are.
This may sound frighteningly similar to programming, and
indeed, an Advent adventure game is a computer program of
a sort.  However, the language used by Advent is designed
to be easy to use, even for non-programmers.  Most people
are able to pick it up very quickly.

The Advent `language' is very versatile, with over forty
recognised words.  That may sound like a lot, but really
there are only a few essentials.  The rest however are
all useful and contribute to the versatility of the
system.  The easiest way to learn the essentials is
probably to be guided through the creation of a game.
So...

Let's write a game!  A first attempt should be a small,
fairly simple game, however, by writing even a simple
game you can become familiar with the Advent system, and
will soon be able to tackle larger tasks.

Let's say that the objective of the game is wander around
a small town, to find a heap of treasure, and store it
safely under your bed at home.  Boring, but suitably
simple!

This part of the manual guides you through the creation
of such a game, introducing many of Advent's features,
and making a number of important points.  However eager
you are to start work on your own game, please do not
skip through this section.  It has been designed as
essential reading, and covers points that are not
mentioned in the second part of the manual.

To begin with, we need to create a new game.  We do this
by entering a filename for the game at the prompt on the
initial screen which appears when Advent is first loaded.

Load up the ADVENT environment and type the name of the
adventure we are about to create at the prompt, then
press RETURN.  If you like, call it MYGAME.  If you wish
to create the game on a specific disk drive, or in a
specific directory, then you should include the drive and
path in the filename, using the standard DOS syntax.

If there is a problem at any stage Advent will display an
Error Box.  This tells you something about the problem,
and may suggest a way to rectify it.

A possible problem at this stage may be that there is no
space on a disk, or the drive door is still open.
Hopefully all will go smoothly, and you will have to wait
for a moment while Advent builds an Index File.

When the initial files have been successfully created the
main menu screen appears.

We are ready to create the game:  For this example we
will be entering data straight into the computer,
however, speaking from experience, I suggest that you
plan your adventures, especially large projects,
extensively on paper before you start typing!


LOCATIONS AND THE VOCABULARY.

The first thing to do is to create the locations which
the adventurer can visit.  Highlight LOCATION TEXT from
the main menu and press return.

The Location text menu gives you the option to INSERT,
AMEND, DISPLAY or PRINT the locations.  The only sensible
thing to do first is to insert, as the other options
require some existing entries.  Highlight INSERT LOCATION
TEXT and press return.

You are presented with the text editor screen, which has
been described previously in this manual.  Advent
automatically chooses the next free location number for
the entry.  This is number one.  Next time you use insert
a text it will be entry number two, and so on.

Type in this location description:


My First Adventure.
Are you ready?


Then press ESC when you are finished.  You are returned
to the location text menu.  Now, although this may not
look like much of a location, it serves a definite
purpose which will be revealed shortly...

Now select display location texts from the menu.  You are
prompted for the number of the first text to be
displayed, type 1 and press return.  The entry is now
displayed.  Hit a key to return to the menu when you are
ready.

Now insert the rest of the entries, just like you did for
the first, by selecting INSERT and pressing ESC when
finished.  The entries are:


Location two.

You are in the downstairs room of your house.  There is a
door to the south and stairs leading up.


Location three.

You are at a crossroads.
Your little house lies to the north, and Mr. Piglet's
grocery shop is to the east
The road extends further to the south, and there is a
church with a big tower, to the west.


Location four.

You are on a road, which is black with a white stripe
running intermittently up the centre.
You can see a junction to the north and a hospital to the
west.
There is a large sign here which reads "SALE, 10% off all
kitchens."
An arrow on the sign points south.


Location five.

You are in a prefabricated kitchen warehouse.  The
kitchens in the warehouse are all prefabricated, but it
would be equally true to say that it is the warehouse
itself that is of a prefabricated nature.
There is, surprisingly perhaps, a sale on, and it must
end Saturday.
The doors are to the north.


Location six.

You are inside Mr. Piglet's grocery emporium.  All manner
of groceries can be purchased here.
The door is to the west.


Location seven.

You are inside the church, which is small and grubby,
with a particularly high ceiling.  The door is to the
east, but the door really is INCREDIBLY HIGH.

Location eight.


You are in the tower of the church, it is cold and
draughty and full of pigeons.


Location nine.

You are in a hospital.  A large nurse is stomping around
with an enormous syringe.  To the east you can see the
street.


Location ten.

Inside the fish.  Gastric juices have already digested
your shoes, and it doesn't look like your socks will last
much longer.


Ok, so you've got ten location descriptions, but 'Inside
the fish' is just silly!  Select AMEND LOCATION TEXT and
enter the location number for `Inside the fish.'  If you
had forgotten which number it was, you could have checked
using the DISPLAY option, which would have told you that
it's number ten.
Type 10 and press return.
The entry appears on the screen where you can edit it.
Erase the whole entry with ALT-F7 and replace it with:


You are in your bedroom, but this morning you do not have
a hangover.
It's going to be a beautiful day.


Press ESC again to finish, and then select DISPLAY to see
all the entries, starting with the first.  Check the
spelling, and AMEND any that need correction.

If you have a parallel printer attached you can make a
printout of these texts.  Select PRINT OUT from the menu
to send the data to the printer.  Make sure it is 'ON
LINE' before you start.

Then select EXIT TO MAIN MENU from the location text
menu, the data is saved, and the disk indexes are updated
before the main menu appears.

So, the locations for the adventure have been defined,
but there are not yet any links between them.  For
example, if the user is at location number six, and types
WEST, we want them to end up in location number three.
The computer doesn't know this, so we need to tell it.
This information will be stored in the MOVEMENT TABLE.

However, before we edit the MOVEMENT TABLE, we must
define the words that the user needs for movement.  So
first we select VOCABULARY from the main menu.

The vocabulary menu appears.  Selecting DISPLAY WORDS
will show a blank display area, indicating that no words
have yet been entered.  Press a key to return to the
vocabulary menu.

Now we need to enter some words.  We will use UP, DOWN,
NORTH, SOUTH, EAST and WEST to describe movements.
To insert a new word into the vocabulary select INSERT
from the vocabulary menu.  You are prompted to enter the
word, so type UP and press return.
The prompt window then displays a prompt asking for a
word value for UP.  The word value is a number between
one and two thousand which is vital for internal use by
ADVENT, however it also allows us to define synonyms, or
words that have the same meaning as each other.  Enter
the word value of one for UP.  A word value less than
twenty-one is used to identify the word as a word
associated with movements.  The interpreter needs to know
this in order to display appropriate messages during the
game.

Repeat this procedure for the following words, giving
them the word values shown.

Word      Word Value

DOWN      2.
NORTH     3.
SOUTH     4.
EAST      5.
WEST      6.

Some players will like to use abbreviations for
directions, typing U to go up, or N to go north.  This is
where synonyms can be used.  INSERT the word U, and give
it the word value one, the same as UP.  Now, these words
have exactly the same meaning to the computer.

Any use of the abbreviation U in either the database
editor or the game interpreter will now be translated
automatically into the word UP.  The first word entered
into the vocabulary with a particular word number is the
word into which any other word with the same number will
be translated by the database editor.

Now insert abbreviations as follows:

Word      Word Value

D         2.
N         3.
S         4.
E         5.
W         6.

Select DISPLAY WORDS from the vocabulary menu to view the
vocabulary.  If you have made a mistake you can use
DELETE WORD to remove the offending word from the
vocabulary.  The computer asks you to confirm that the
word is to be deleted.  This is because deleting a word
can have effects elsewhere in the database.  If the word
has synonyms, you are safe, but if a word is deleted that
doesn't have a synonym then any Event, Status, Movement
or Object Word entry where that word is used will be
removed from the database.

Use DISPLAY WORDS again to ensure that the vocabulary is
as intended, and use EXIT TO MAIN MENU to when you are
happy.


THE MOVEMENT TABLE.

Having defined the movement words in the vocabulary, we
can create the movement table.
We are going to create a movement table to link the
locations as shown in this map:


                    +---------------+
                    | Bedroom       |
                    |               |
                    |               |
                    | 10    U       |
                    +-------|-------+
+---------------+   +-------|-------+
| The church    |   | Downstairs    |
| tower         |   |               |
|               |   |               |
| 8     U       |   | 2             |
+-------|-------+   +-------|-------+
+-------|-------+   +-------|-------+   +---------------+
| A church      |   | A crossroads  |   | Mr Piglet's   |
|               |   |               |   | shop          |
|               |---|               |---|               |
| 7             |   | 3             |   | 6             |
+---------------+   +-------|-------+   +---------------+
+---------------+   +-------|-------+
| A hospital    |   | A road        |
|               |   |               |              N
|               |---|               |           /|\
| 9             |   | 4             |            |
+---------------+   +-------|-------+      W     |    E
                    +-------|-------+      ------+-----
                    | A warehouse   |            |
                    |               |            |
                    |               |            | S
                    | 5             |
                    +---------------+


Select MOVEMENT TABLE from the main menu.  Notice that
the movement table menu has no option for inserting
entries.  This is because an entry is created
automatically for every location defined in the database.
The entries start out empty, so they must be AMENDED in
order to change them.

Select AMEND from the menu and enter the number three.
This means we are editing the movement data which will
apply when the player is at location three (at the
crossroads).

Enter the following:


NORTH 2 SOUTH 4 EAST 6 WEST 7


and press ESC to finish.

If you have made a mistake you will be warned of it, and
the cursor will be positioned close to it, to allow you
to correct it.  If this happens, check that your entry
matches exactly the one above.

So, you've got this entry, but what does it mean?

The words, as you have probably realised, are words from
the vocabulary.  The numbers, less obviously, are
location numbers.  The movement table works by comparing
the movement table entry for the current location, with
the users command.  For example, if when at location
three, the user types NORTH, the interpreter looks for
the word NORTH in the movement table entry for location
three.  It finds it, and looks to see what number
follows.  It will find the number two.  The player is
then moved to location number two.  Had they typed EAST
they would move to location number six and so on.

The movement table must be completed like this for each
location in the game.  Location four is the second most
complicated:  If at location four the player would arrive
at location three by typing NORTH or at location five by
typing SOUTH.  Typing WEST would take them to location
nine.  Try to work out the correct movement table entry
for yourself and enter it.

You should have entered for location four:


NORTH 3 SOUTH 5 WEST 9


Correct this using the AMEND function if necessary, then
enter the following entries for the other locations.
Remember that you can use the single letter abbreviations
if you wish, they will be translated into full words by
the editor.


Location 1:         NORTH 10

Location 2:         UP 10 SOUTH 3

Location 5:         NORTH 4

Location 6:         WEST 3

Location 7:         EAST 3 UP 8

Location 8:         DOWN 7

Location 9:         EAST 4

Location 10:        DOWN 2


DISPLAY the entries to check them, and correct any
mistakes with AMEND.

Notice that each doorway requires a separate statement
for each direction that the player may move through it.
For example the location seven entry must describe the
movement EAST to location 3, even though the same door
has been identified by WEST 7 in the entry for location
3.  This `feature' is important as it allows the creation
of one way doors, doors that are locked, and even
fiendish mazes where going EAST then WEST need not return
the player to the same place as where they started!

Use EXIT to return to the main menu.


TESTING THE ADVENTURE.

We are finally able to test our adventure.  It is far
from complete, but we ought to be able to move around
between the various locations.

Choose TEST ADVENTURE from the main menu.  You may have
to wait for a moment whilst Advent loads the interpreter
program...

The interpreter begins by asking you if you want to use
DIAGNOSTICS.  This facility enables us to view the states
of a number of flags as we play the game.  In this case,
the feature will be of little use, so reply with N for
No.  We will however use diagnostics a little later when
we get more adventurous!

Note next the two commands which are added to the
vocabulary when we are testing a game.  They are prefixed
with asterisks to minimise the risk of clashing with
words in your game.  They should be self explanatory.

Hit a key to begin testing.

Let's explain about location number one:  In this case it
doesn't look much like a location description, because it
isn't:  The first important point is that the game always
begins by putting the player at location one.  The second
is that, later we are going to make it dark at the beginning
of the game, and, because of the way the interpreter works,
we can't make it dark immediately that the player lands in
location one at the start of the game.  The simple solution
is to make location one a dummy first location, then make
it dark, and then move them to the first 'real location'
of the game.  Until then we can use NORTH to move to the
first real location, the bedroom.  You should now
experiment, try moving in all directions from all
locations, and check that the results correspond to the map.

When you are finished type *EXIT to finish.  You will be
returned to the editor main menu.

If you found any problems with the movements, you should
now check the movement table entries and make the
necessary corrections.


DARKNESS AND THE STATUS TABLE.

Now, what was that I said about making it dark at the
beginning of the game?  How do we do that?

We need to place an entry in the status table:  Remember
that the status table stores a set of entries each of
which contains conditions, and actions.  The table is
checked just before every player input, and if the
conditions in ANY entry are satisfied, the associated
commands will be executed.

Choose status table from the main menu, and choose to
insert an entry.  The editor asks you to insert two
'status words'.
Now, the status words serve simply to identify the entry,
(and can have an effect on the order of storage in the
database) so you can choose any two words from the
vocabulary which you feel describe the purpose of the
entry you are about to make.  Alternatively, either of
these words may be wildcards, the asterisk character '*'.
In this game there will be very few status table entries,
and we do not have suitable vocabulary words to make a
description, so we simply enter two asterisks, separated
by a space.


* *


The asterisk is used here, and more importantly in the
event table, when we want to tell Advent that we REALLY
DON'T MIND what word is in this position.  This should
become clear later.

We are then moved to the editor to make the entry.
Notice that the status words (asterisks in this case) are
at the beginning of the entry.  Do not delete them, as
they are important.

What do we want this entry to do?

If the player is at location one, and it is the beginning
of the game, we must make it dark, then we will wait for
a key press, and move the player onto the location where
they start the game.

We could write this:

IF (at location 1) and (start of game)
THEN (make it dark), (wait for a key press),
(move to location 10) and (describe the location)

Many of these conditions and actions translate directly
into Advent commands, others are less simple.  The
components of the entry are described below.

(at location 1) is tested with the condition AT 1, which
is satisfied if the player is at location 1.

(start of game) is tested by checking that the turns
count is set to zero.  The turns counter is stored in
flags 55 and 56 (see Appendix 1), so we test that
both are zero with EQ 55 0 EQ 56 0

(make it dark) is performed by setting the value of flag
number one.  Any non zero value will do, but Advent has a
command SET, which sets the value to the largest
possible, 32767.  We use SET 1

(wait for a key press) is handled by the command ANYKEY.
The interpreter displays the prompt PRESS ANY KEY TO
CONTINUE, at the bottom of the screen, and waits for a
key press.

(move to location 10) is handled by the command GOTO
which moves the player to the specified location number.
We use GOTO 10.

(describe the location) translates directly to DESC.
Thus the entry becomes


* * AT 1 EQ 55 0 EQ 56 0 SET 1 ANYKEY GOTO 10 DESC


Enter this, then press ESC to finish editing.  Note that
you do not need to add the asterisks again.  If the
editor detects a syntax mistake, the cursor will be
positioned close to the error for you to correct it.
Press ESC again when all corrections have been made.

One further change needs to be made.  The movement table
entry for location one contains 'NORTH 10', which is now
redundant.  Amend the entry to remove this, making the
entry blank.


THE EVENT TABLE.

So it will be dark at the beginning of the game, but the
actual situation that we want to create is as follows:

a)  It is dark at the start of the game.
b)  The player cannot go down the stairs when it is dark.
c)  The player is able to turn the light on.


The movement table contains an entry 'DOWN 2' at location
one.  This means that the player can always go DOWN, to
location two.  This is not what we want, as we want to be
able to stop them doing this, if it is dark.

I am about to demonstrate then, how we can handle special
movement situations outside the movement table by using
the EVENT TABLE, and also the use of the event table to
turn a light on.

First we remove the movement table entry for location
ten.  Amend this so that the entry is blank.

Then we add some words to the vocabulary:  These are the
new words that will be needed for the darkness/going
downstairs part of the game.

Insert the following words into the vocabulary:


Word      Word value

ON        109
LIGHT     110
LAMP      110


Notice that LIGHT and LAMP are synonyms.  They share
exactly the same meaning, as far as Advent is concerned.
We must also define some messages that are required.
Insert the following messages:


Message 1.
You switch on the light, you can see much more clearly
now.

Message 2.
You shuffle around in the dark, but cannot find the
stairs.


We can now add an entry to the EVENT TABLE.  This is very
similar to the status table that we used earlier, but it
is dependant on the players input.  I will demonstrate:

From the main menu, choose EVENT TABLE.

Select INSERT EVENT TABLE ENTRY.

For the event words, enter 'DOWN *' (Two words separated
by a space) and press return.
You are now in the text editor.  Type in the entry so
that you have the following:


DOWN * AT 10 ZERO 1 GOTO 2 DESC


and press ESC to finish.

Again, if the entry contains a mistake or syntax error,
you will be prompted to correct it before you can quit
the text editor.
Using the semi-coded notation introduced earlier, the way
the entry works can be seen:

IF (players first word is DOWN) BUT (we don't care what
the second word is) AND (the player is at location ten)
AND (it is NOT dark)

THEN (move to location 2) AND (describe the location)

We have thus covered the situation where the player tries
to go down, and succeeds, because it is not dark.  We now
INSERT a similar entry for the situation when it IS dark,
and the move is prohibited.
INSERT the following entry into the event table:


Event words: DOWN *  (again)

Complete entry:
DOWN * AT 10 NOTZERO 1 MESSAGE 2 DONE


The entry works as follows:

IF (players first word is DOWN) AND (at location ten) AND
(it is dark)

THEN (display message number two 'You shuffle around...')

We now have an entry to handle both situations that may
arise:  If it is dark, the player is told that they can't
go downstairs, and if it is light they are allowed to go.
Easy eh?

You will notice that we now have two event table entries
that share the same event words, DOWN *.  This is not a
problem, as Advent can handle any number of entries like
this.  You will notice however that the process of
AMENDING an entry changes somewhat.  If you try to AMEND
DOWN *, you will be able to edit the first DOWN * entry
in the table, pressing ESC will take you to the second,
and if there was a third, pressing ESC again would take
you to that one.  In this case, pressing ESC the second
time will return you to the menu.

What remains now is to allow the player to turn on the
light.  We have words and messages ready, and we assume
that there is a light in the room so we needn't add it as
an object.  This is done with a further entry to the
EVENT TABLE:

Enter the following:

Event words: ON LIGHT

Complete entry:
ON LIGHT NOTZERO 1 CLEAR 1 MESSAGE 1

Which could be read as:

IF (the player types ON LIGHT) and (it is dark, i.e. flag
one is non zero)

THEN (clear the value in flag one, i.e. make it light)
AND (display message number one)

Notice that we do not check that the player is at
location ten.  This is not necessary because the player
cannot leave location ten while it is still dark.

I should now mention something about the way that Advent
handles player inputs.

If you were playing a game, it is unlikely that you would
type ON LIGHT to turn on a light.  Possible inputs
include:

TURN ON THE LIGHT
TURN ON LIGHT
SWITCH ON THE LIGHT
SWITCH ON THE $*!@ING LIGHT etc...

But the event table would get very full if we had to
anticipate all these entries in advance.  Fortunately,
our ON LIGHT entry handles all of the above for us.  What
actually happens is that the interpreter searches the
players input string for words that it knows, i.e. words
that are stored in the vocabulary.  It then attempts to
match the first two recognised words with the event words
in the event table.

Provided that the words TURN and THE are not in the
vocabulary, Advent will pick out the words ON and LIGHT,
and these will satisfy the event entry ON LIGHT.
Similarly, assuming that SWITCH is not in the vocabulary,
SWITCH ON THE LIGHT will be reduced to ON LIGHT also.

There is obviously the possibility that the word SWITCH
might be needed elsewhere, and has to be stored in the
vocabulary.  In situations like this, and there will be a
few in a big project, you must use your experience to
choose vocabulary and event words that do not clash.
Advent also provides the HASH STRING method, which can be
useful in some of these situations.  But really, what's
the fun in Adventuring if the machine doesn't reply 'I
don't understand' a few times?

What if the player types TURN THE LIGHT ON ?

This, and constructs like it would not be picked up by
Advent, as the words LIGHT and ON are in the wrong order
to satisfy the event words for ON LIGHT.  We will add a
further entry:

Event words: LIGHT ON

Complete Entry:
LIGHT ON NOTZERO 1 CLEAR 1 MESSAGE 1

You will notice that the conditions and actions are
identical to those used in ON LIGHT.  You should now be
fairly happy that with only two entries we have covered
most of the ways that a player might try to turn on the
lights.

If you like, and I'm sure you will, you can test the
adventure again.  This time ask for diagnostics by
replying Y for Yes to the question.  You are then asked
which flags you want to watch.  Enter 'L' to have Advent
monitor the current location number, and watch it appear
in the DIAGNOSTICS WINDOW.  We are also making use of
flag one, the darkness flag, so select that by entering
the number '1'.  Finally enter 'X' to exit the diagnostics
setup screen.  Hit another key, and we are ready to start
playing!  Remember to watch these flags whilst you are
playing.  You should notice flag 1 change as darkness is
'turned on' and 'turned off'

Notice also the diagnostics window at the bottom of the
screen.  This is, of course, not available for display in
the completed game.

This time, we do not get an input prompt, but are asked
to 'PRESS ANY KEY TO CONTINUE' at the bottom of the
screen.  This is our ANYKEY command in action.  When a
key gets pressed you should be moved to the first
location, where it is dark.   Try it, and verify that
this is the case.

Try to go downstairs by typing 'DOWN'  The message should
appear to tell us that this is not possible in the dark.

Try to 'TURN ON THE LIGHT' or any other similar phrase,
and verify that it works.  Now, typing 'DOWN' should take
us downstairs, from where we are able to explore the rest
of the locations.

Type *EXIT when you are finished.  This returns you to
the main menu.


SOME MORE BITS AND PIECES.

We are now ready to add more features to the game:  first
of all, a few commands to make life easier for the user.

We are going to add INVENTORY and DESCRIBE and QUIT
commands.  The first gives the player an inventory, or
list of objects carried, and the second will be used to
redisplay the current location text.  Quit lets the
player stop playing before they have completed the game,
and we will make it tell them how many turns they have
used.

First we add the necessary words to the vocabulary:

Word      Word Value

INVENTORY 107       (this will be shortened to INVENTOR)
I         107
DESCRIBE  108
DESC      108
LOOK      108
QUIT      112


And then we add these very simple entries to the event
table:

To handle the location redescriptions,

Event words: DESC *

Complete entry:
DESC * DESC


To handle the inventory display,

Event words: INVENTORY *

Complete entry:
INVENTOR * INVEN DONE

And to handle the Quit facility,

Event words: QUIT *

Complete entry:
QUIT * QUIT TURNS END

The action INVEN is provided by Advent to display the
inventory list
You could now test the game to check that these new
commands work.


OBJECTS.

We are now ready to add objects to our adventure.  An
object can be any item that appears in the game.  Often
they can be manipulated by the player, picked up, put
down etc.  If there is a need for an item that can be
moved, made to disappear, changed into something else,
etc, etc... then you should make it an object.

We can define the objects for our game using the OBJECT
TEXT menu.  Select this now, and use the INSERT OBJECT
TEXT option to enter the following object descriptions,
just as you would a message or location text.


Object 1.
A pile of shiny jewels (they must be worth quite a lot of
money)

Object 2.
A tin can, with no label.  Whatever could be inside?

Object 3.
An open tin can.

Object 4.
A ladder.

Object 5.
A key. (A label on the ring reads 'Tower')

Object 6.
A tin opener.


Having defined the texts to describe the six objects in
the game, we must define further properties, such as the
locations at which they appear, and the words used to
refer to them.

The location at which an object first appears in the game
is set using the OBJECT START LOCATION menu.  A bit like
for items in the movement table, an object start location
entry is maintained automatically for every object that
you have defined.  You use the AMEND option to change an
entry.

You are prompted to enter the object number for the
object whose start location you wish to change, and
provided that you enter a valid number, the first few
characters of the object text are displayed.  You must
then enter the start location which must be either a
valid location number, or one of the letters 'C' 'W' or
'N' which are used if you want an object to be initially
'Carried', 'Worn' or 'Not created'.

You should now enter the start locations for our objects
as follows:

Object 1       at location 8
Object 2       at location 6
Object 3       Not created (enter 'N')
Object 4       at location 5
Object 5       Not created
Object 6       at location 4


Then exit to the main menu.

If you were to test the adventure now, you would find the
objects at their respective start locations, but would be
unable to manipulate them, as we have not defined the
ways in which this can be done.

There are actions GET and DROP which can be used in the
event and status tables for the manipulation of
individual objects.  It is also possible to CREATE and
DESTROY objects, they are not actually created and
destroyed from/to nothing, rather, objects which have
been defined in the database can be brought into
existence (and removed from it) as far as the player of
the game is concerned.

So, we could add an event table entry for each object
along the lines of:

GET TIN GET 2 OK
GET JEWELS GET 1 OK
DROP TIN DROP 2 OK
DROP JEWELS DROP 1 OK

When you consider that Advent can cope with upto a
thousand objects, each of which can be taken and dropped,
and some of which can be worn and removed, this would
more than fill the three thousand event entry spaces
available.  You are probably thinking that there must be
an easier way.  So there is:

The OBJECT WORD TABLE defines a single word from the
vocabulary to be associated with each object that you
wish to manipulate.  The objects can then be manipulated
using the AUTOG, AUTOD, AUTOW, and AUTOR actions in the
event table.

Most objects thus defined can be taken, carried, and
dropped by the player.  If the word value of the object
word is in the range 21 - 99, that defines an object that
can be worn and removed, as well as taken and dropped.
By leaving the object word blank you create an object
that is not affected by the AUTOx actions.  Such an
object can always be manipulated by the GET, DROP, CREATE
etc. actions mentioned earlier, as indeed can any object
that does have an object word, by using them directly in
the event or status tables.

Before defining our object word associations, we must
define the words themselves, so choose the VOCABULARY
option from the main menu, and insert the following
words:


Word      Word value

JEWELS    100
CAN       101
TIN       101
LADDER    102
KEY       103
OPENER    104
GET       105
TAKE      105
DROP      106
PUT       106


Obviously, the first six words in this list will refer to
objects whilst the last four are verbs that the player
can apply to them.

We can now define the object words, so select OBJECT
WORDS from the main menu.

Select DISPLAY OBJECT WORDS from the menu, and notice
that the object word for each of the objects, one to six,
is listed as NOT DEFINED.  Return to the OBJECT WORD menu
and select AMEND.  Like the screen for the object start
location, you are prompted for an object number, then the
beginning of the object text is displayed whilst you are
prompted for new object word.  Note that object words
must be a valid word from the vocabulary.

AMEND each object word entry as follows.

Object 1       JEWELS
Object 2       CAN
Object 3       CAN
Object 4       LADDER
Object 5       KEY
Object 6       OPENER


You will notice that the word CAN is used for two
objects.  This could cause problems if both cans were in
the same place at the same time, so that it would be
impossible to identify one unique object.  This is not a
problem in this case, as the two cans, one opened and one
closed, are mutually exclusive, i.e. the closed can will
be 'destroyed' as soon as it is 'opened' and the open can
will be 'created' in its place.

Now we must simply add the AUTOG and AUTOD entries in the
event table. That is done with the following entries:

Event words: GET *
Complete entry: GET * AUTOG OK

Event words: DROP *
Complete entry: DROP * AUTOD OK


The way that these work is that when the user tries to,
say, GET an object, the event table entry GET * will be
satisfied.  The AUTOG action then checks the next
recognised word in the players input, and if it matches
the object word for an object which is present at the
current location, that object will be picked up.  AUTOD,
AUTOW(ear) and AUTOR(emove) work in exactly identical
manners.


HASH STRINGS.

You should now test the adventure again.  You should find
that you can now pick up objects and put them down in
different places.  It's really that simple!

While testing, go to location four, the road outside the
hospital.  You should find the tin opener here, unless
you have already moved it, in which case, move to the
location where it is.

Attempting to pick up the tin opener is easy, if we know
the object word:  'GET OPENER' works fine.  But suppose a
player types 'GET THE TIN OPENER.'  The AUTOG action will
recognise the word TIN before it sees OPENER, and will
try to GET THE TIN.  Of course, this will produce an
incorrect response, such as 'It's not here' although the
player knows that the tin opener is in front of them.

One solution comes in the form of a HASH STRING.  Hash
strings are a powerful alternative to the EVENT WORDS
that we usually use to identify an event table entry.

A hash string is entered where you would normally enter
your pair of EVENT WORDS.  Instead you type a hash
character '#' followed by a number of words.  These words
need NOT be words from the vocabulary.

The interpreter checks to see if the players entry
matches any of the HASH STRINGS before testing the rest
of the event table.  (This is why hash entries are listed
at the beginning of the event table.)  When testing the
players input against a hash string, the interpreter
tests that each of the words in the hash string are
present in the players input, in the order that they
appear in the hash string.  They need not be consecutive.

Return to the editor and insert the following entry into the
event table:

Event words: #GET TIN OPENER
Complete Entry:
#GET TIN OPENER GET 6 OK

For our tin opener problem, the hash string entry in the
event table:

#GET TIN OPENER

would be satisfied if the user entered

'GET TIN OPENER', 'GET THE TIN OPENER', or 'GET THE GREEN
TIN OPENER'

It would not, however, be satisfied by:

'TIN OPENER GET'

or any other phrase with the same words in a different
order.

We also need to add a similar entry for dropping the tin
opener, by adding an event table entry:

Event Words: #DROP TIN OPENER
Complete entry:
#DROP TIN OPENER DROP 6 OK


A WORD OF ADVICE WHEN USING HASH STRINGS.

The hash string facility is powerful, and in many
situations provides a simple way out of a tricky corner.
Without hash strings, the above example would have been
impossible without prompting the player for further
information.  Hash strings however, make hard work for
the interpreter:  Every hash string has to be tested,
every time the player takes a turn, and that can slow
things down.  Another disadvantage is due to the fact
that the hash string need not be composed of words from
the vocabulary.  Using the vocabulary gives a definite
structure to the database, helping to keep the game easy
to add to, maintain and modify.  So, my advice is to use
hash strings, and take advantage of the extra flexibility
that they bring, but only if you are satisfied that you
can't achieve your objective using 'standard' event table
entries.


LADDERS AND THINGS.

Well, the adventure is beginning to take shape.  All that
remains is to provide a means by which the player can
enter the church tower to find the treasure...

The way we are going to make them do this is to climb the
ladder, whilst in the church.  Then, if they are carrying
the appropriate key, they will be allowed into the tower.

The following examples demonstrate the way in which the
author must try to anticipate the players commands.  For
example, if we give them a ladder, we must expect them to
try to climb up it.  It would be silly if the interpreter
just said "I can't."  Most people can climb ladders!

There are three situations that we must consider:

1)   The player climbs the ladder, in the church, and has
the key.  They are allowed into the tower.
2)   The player climbs the ladder, in the church, but
does not have the key.  They are not allowed into the
tower.
3)   The player climbs the ladder, but is not in the
church.  We are going to make them fall off, and send
them to the hospital.

First of all, as always, we must add to the vocabulary.
The word we need is CLIMB.

Word      Word value

CLIMB          1


Notice that we make CLIMB synonymous with UP, as this
causes the interpreter to reply as if CLIMB were a
movement word.  e.g. it will say "I can't go in that
direction" rather than simply "I can't."

And we must insert the following messages:

Message 3
You climb a couple of rungs up the ladder, which is quite
a feat, as you can't find anything to rest it against.
Eventually the inevitable happens, and you fall, bouncing
your head off the floor, a couple of times.

Message 4
You open the tin, and out falls a key.  It's funny, you
were expecting baked beans or dog food, weren't you?

Message 5
You climb the ladder, and discover a trapdoor in the
ceiling.  It is locked.  Quite excited by this find, you
return to the floor to regain your breath.

Message 6
You climb the ladder, and, using the key that you found
in the tin, open the trapdoor in the ceiling.
You carry on through the trapdoor...


OK, so now you know where we're going to find the key
too!

We can now handle the event table entries for the players
attempts to climb the ladder.

Taking the three situations in turn:

1)   The player climbs the ladder, in the church, and has
the key.  They are allowed into the tower.

IF (player types CLIMB LADDER) AND (is in the church) AND
(the ladder is there) AND (they are carrying the key)

THEN (display message six), (wait for a key press),
(transport them to location eight, the tower)  and
(describe the location)

We have to enter the following into the event table:

CLIMB LADDER AT 7 PRESENT 4 CARRIED 5 MESSAGE 6 ANYKEY
GOTO 8 DESC


2)   The player climbs the ladder, in the church, but
does not have the key.  They are not allowed into the
tower.

IF (player types CLIMB LADDER) AND (is in the church) AND
(the ladder is there) BUT (they do not have the key)

THEN (display message five)

We insert the following into the event table:

CLIMB LADDER AT 7 PRESENT 4 NOTCARR 5 MESSAGE 5


3)   The player climbs the ladder, but is not in the
church.  We are going to make them fall off, and send
them to the hospital.

IF (player types CLIMB LADDER) AND (is not in the church)
BUT (the ladder is at the same location as the player)

THEN (display message three) AND (wait for a key press)
THEN (send them to location 9) AND (describe the
location)

We insert the following event table entry:

CLIMB LADDER NOTAT 7 PRESENT 4 MESSAGE 3 ANYKEY GOTO 9
DESC


We have already noted that the database can store
multiple event table entries with the same event words.
In such a case, the entries are stored IN THE ORDER THAT
YOU ENTERED THEM.  Whilst it didn't matter in this case,
it can be important, as after one entry, whether its
actions were executed or not, execution  can 'fall
through' to the next.  Using the action DONE at the end
of an entry can be useful if you particularly want to
prevent such a fall-through.

If you now test the adventure you will find that climbing
the ladder in the church tells you that the trapdoor is
locked.  Trying to climb it anywhere else ends you up in
the hospital.

Now we have to do the bit that lets the player get the
key out of the tin.  It's really easy..
.
We have got the message we need (number four), but don't
yet have a word for OPENing the tin.  Add the following
to the vocabulary:

Word      Word Value

OPEN      111


Now we are going to create and destroy some objects.  In
order to get the key out of the tin we need an event
table entry along the lines of

IF (the player types OPEN TIN) AND (they have the closed
tin) AND (they have the tin opener)

THEN (make the closed tin go away) AND (make the open tin
and key appear in its place) AND (display message four)

Which we do with the event table entry,

OPEN TIN CARRIED 2 CARRIED 6 DESTROY 2 CREATE 3 CREATE 5
MESSAGE 4

And we are nearly there!

If you test the adventure now, you should be able to get
the key out of the tin by fetching the tin opener and the
tin, and typing OPEN TIN.  You will have to pick up the
key, and then you can try to climb the ladder in the
church.  If all goes well, you will find yourself in the
church tower, and the JEWELS should be there.  You can
pick them up, go back down to the church, but what then?

If you remember, we said that you had to take the jewels
back to your bedroom, and hide them under the bed?  Well,
were going to do that, and were going to do it with the
status table, just for a change.

Make the following entry to the STATUS table.

DROP JEWELS AT 10 CARRIED 1 MESSAGE 7 ANYKEY TURNS END

How does this work?

IF (the player is at location ten) and (they are carrying
the jewels)

THEN (display message seven), (wait for a key press),
(display the turns count) AND (that the end of the game,
so ask if they want to play again.)

But I'm sure you can work that out for yourself by now.

Well, in a way the game is complete.  You can play it,
and you can win it.  In some ways the game is far from
finished.  What happens if you try to buy a kitchen?  If
you stand in the road for too long, will you be injured
by a passing bus?

When you have finished a game, you should be satisfied
that the interpreter will give a sensible response to
anything the player might reasonably try to do.  It is
these final touches that make a game a pleasure to play.
If the player swears at the interpreter, do they get
locked in a dark hole?

Let's add one last thing to the game.

So far we have done things with objects, but we have
somewhat neglected the four hundred user flags that
Advent maintains for us.  Remember, a flag is just like a
box that we can store a number in.  Programmers will like
to think of them as variables, but then, a variable is
just a box that we can put numbers in!
We have come across some flags already.  Flag 1 is the
darkness flag, and by changing the value that it holds we
can control whether the player can see.  We have also
seen that the number of turns taken is stored in flags
fifty-five and fifty-six.  These are SPECIAL PURPOSE
FLAGS.  The job they do has already been defined, and you
cannot change it.

Most of the other flags are MULTI PURPOSE to a greater or
lesser extent.  Some of them count down automatically,
some of them count down if it is dark, some are decreased
every time a location is described, many of them do not
change unless you tell them to, and so on.

The FLAG NUMBERS that correspond to these different
functions are listed in Appendix 1.

We are going to use a flag that counts down every turn
(Flag 60) to create a situation whereby after falling off
the ladder, we are not allowed out of the hospital for
four turns.

How do we do that?

We preset the value of the flag to four as the player
falls.  After four subsequent turns the value has fallen
to zero.

Amend the event table entry for CLIMB LADDER, so that the
entry which handles falling off the ladder becomes:

CLIMB LADDER NOTAT 7 PRESENT 4 LET 60 4 MESSAGE 3 ANYKEY
GOTO 9 DESC

This addition merely makes the value of flag 60 equal
to four when the player falls.

We will replace the movement table entry for getting out
of the hospital with an entry in the event table which
tests the value of the flag before letting us out.

So, amend the movement table entry for location nine (the
hospital) so that it is blank.

Then we add one last message.

Message 8
The nurse pokes you with the sharp end of her syringe.
"Back to bed!" she cries, "You've had a nasty fall."

Then two event table entries, one to handle the situation
when you aren't allowed out of the hospital, and one to
let you out when you have had your four turns:

EAST * AT 9 NOTZERO 60 MESSAGE 8

and

EAST * AT 9 ZERO 60 GOTO 4 DESC


You will be able to see how these work.  Test the
adventure, and use diagnostics to watch the value of flag
60.  Notice that it is decreased every turn, immediately
after you make your input.  This means that you are
allowed out on the fourth attempt.

You will probably find, like I do, that a certain amount
of trial and error is required before you get all your
flags counting just the right numbers!

And that really is all we are going to do.

There are loads of other conditions and actions that we
have  not used in this simple game.  The ones that we
have used are probably the ones that you will use most
often.  The others you may use only occasionally, but
can be very useful.  In particular there are a number of
conditions and actions concerned with manipulating the
values stored in flags.  They are all listed in the
second part of this manual with a detailed description of
exactly how they work.

Some particular commands that are handy (just to whet
your appetite) are:

SWAP, to exchange the positions of two objects.

PLACE, to put an object in a specific location.  Create
scary monsters that wander around the game!

LOAD and SAVE, allow the user to save their game position
to disk. An essential if you are writing large games that
might take a long time to solve.

CHANCE, a condition that is satisfied some of the time!
You can create games that are different every time you
play, or change the route that your monster takes!


BEFORE YOU EMBARK ON YOUR OWN PROJECT...

A few words of advice!

Be sure to read through the rest of this manual.  You can
only really be in control of the situation if you
understand how Advent is working, and why it behaves the
way it does.

Plan your adventure carefully.  It is tempting to turn on
the computer start entering data, but more than likely
you will make a real mess.  You'll get your event and
status table entries in the wrong order, lose track of
what flag does what, and generally do a bad job.  Get at
least an outline not only of the map, but also of the
problems you are going to set, written down on paper
before you even turn the computer on.

Read Appendix 5 and the notes at the beginning of this
document before you sell your finished adventure.


RUNNING A COMPLETED GAME.

When your game is finished, it is not very desirable to
have to load the Advent database editor every time you
want to run it.  Instead, the program PLAYA.EXE is called
directly.

At the DOS command line type:

PLAYA GAMENAME

Where GAMENAME is the filename of the game that you wish
to play.  GAMENAME may include standard disk drive and
directory specifications.

When you are playing a game in this way, there are no
options for diagnostics, and there are no added (*)
commands.  Execution begins straight away at location
one.  You should make sure your game has a QUIT or
similar command envoking the END action, or you will not
be able to stop playing if you want to.
__________________________________________________________
__________________________________________________________


ADVENT USER MANUAL - PART 3.
INTERPRETER AND LANGUAGE REFERENCE.


RUNNING ADVENT.
The Advent database editor program, ADVENT.EXE is started
by typing:

ADVENT

at the DOS prompt.  Adding the command line switch /Q
will run Advent in 'quiet mode' if you prefer not to have
Advent beep at you.  This is particularly useful if your
computer, like mine, has an over enthusiastic
loudspeaker:

ADVENT /Q


Advent, on loading will prompt you for a filename.  If
the file that you specify exists, Advent will attempt to
load it.  Otherwise you will be given the option of
creating an adventure of that name.  If you create a new
game there may be a slight delay while Advent builds the
index and initial data files.

You will then be presented with the main menu screen.
The use of the menus and the Advent database editor is
demonstrated in part one of this manual.


A DESCRIPTION OF THE ADVENT DATABASE.

THE VOCABULARY.

The vocabulary contains the list of words that the
interpreter will understand.  Each word is allocated a
Word Value by the user.  Words with the same word values
are synonyms, i.e. they are considered to have the same
meaning by the editor and interpreter.

Words associated with movements should be given word
values LESS THAN 21.  This allows the interpreter to give
sensible messages when the player tries to move, e.g. 'I
can't go in that direction' rather than 'I can't.'

Words associated with objects that can be worn should be
given word values in the range 21 to 99 inclusive.  These
words will show as GDWR in the object word table, rather
than just GD.

Word values of 100 and greater can be used for any word,
including verbs, and objects which can be manipulated but
not worn.  The largest word value permitted is 2000.


THE MESSAGE TEXTS.

This table stores the messages which are used in the
adventure.  The first message is number one.


THE LOCATION TEXTS.

This table stores the texts which describe the locations
in the adventure.  Numbering begins at number one, which
is the location where the player begins the game.


THE MOVEMENT TABLE.

Entries are created automatically in this table for every
location which is defined in the location texts.  The
entry for a particular location defines the exits from
that location with entries in the form:

WORD NUMBER WORD NUMBER ... WORD NUMBER

The words must be words from the vocabulary, and the
number following that word is the location to which the
player will be moved when they type the word or one of
its synonyms as the first word of their command.  The
number must be a valid location number.

If a word is removed from the vocabulary, such that no
synonyms remain, any movement table entry using that word
will be reset.

If movements are handled in the event or status tables,
i.e. using GOTO, then the movement table should not
include those movements.


THE OBJECT TEXTS.

This table stores the description texts for objects in
the game.  Any item that can be moved around or otherwise
manipulated should be defined as an object.

Note that object one is a special case in that it is
treated as a source of light by the interpreter, i.e. it
cannot be dark if object one is present.  Object one will
usually be described as a torch or lamp.


THE OBJECT START LOCATIONS.

At the beginning of the game the objects are placed at
locations as defined in this table.  A valid start
location is any valid location number, or one of three
special cases: Not Created, Carried or Worn.

When an object is defined in the object text table its
start location is automatically set to Not Created.


THE EVENT TABLE.

The event table defines the way the interpreter should
react to typed commands by the player.  The form of the
entries is as follows:

WORD1 WORD2 CONDITIONS ACTIONS

Where WORD1 and WORD2 are words from the vocabulary, and
CONDITIONS and ACTIONS are chosen from those conditions
and actions implemented by Advent.  CONDITIONS are
optional, as in fact are ACTIONS but it is unlikely that
an entry without actions would be used.

Words one and two may be optionally replaced with the
wildcard character '*'.  Typically, word two will be a
wildcard to signify that the players command will be a
single word.

The actions listed will only be executed if the players
command matches the event words WORD1 and WORD2, and the
list of conditions are satisfied.

As an alternative to the event words, a hash string may
be entered.  This consists of the hash character '#'
followed by a number of words (usually three or more)
separated by spaces.  The actions will then be executed
only if each of the words in the hash string are found in
the players command, in the order that they appear in the
hash string, and the conditions are also satisfied.  The
use of hash strings is discussed in part one of this
manual.


THE STATUS TABLE.

The status table is similar to the event table in that it
contains lists of conditions and actions in the form:

WORD1 WORD2 CONDITIONS ACTIONS

The Status Words, WORD1 and WORD2 are used to identify
the entries and to position them in the table but are not
matched to players inputs.  Thus, the actions in a status
table entry will be executed simply when the list of
conditions is satisfied.

Obviously, hash strings are not used in the Status Table.

The status table is tested between the players turns and
can be used to cause things to happen that
are not initiated by the player.


THE SYSTEM MESSAGES.

These texts are preset to defaults, and are used by the
interpreter to communicate with the player.  Their use is
identified in the description of the interpreter.  It is
possible to edit these texts to suit you preferences and
to customise your games, but you should always keep the
meaning of the messages the same.


THE OBJECT WORD TABLE.

The Object Word table stores a word for each object that
has been defined in the Object Text table.  The entry is
initially set to 'Not Defined' but can be changed to any
word in the vocabulary.  The word can then be used by the
powerful AUTOG, AUTOD, AUTOW and AUTOR actions to
identify objects in the event table.  For objects that
can be worn and removed, the object word should be a word
with a word number between 21 and 99 inclusive.


FLAGS.

Flags in Advent are a bit like `variables' in
programming, but are really very simple.  Each flag can
be thought of as a store which can hold a whole number,
from zero to 32767 (which is significant in computing).
There are four hundred such flags available in Advent,
some of which have special uses, and others which do not.
They are identified by their number, from 1 to 400.

The ACTIONS in the event and status tables allow control
of the numbers stored in the flags whilst the game is in
progress, for example by adding to their values, or
subtracting from them.  Some of the CONDITIONS allow the
comparison of flags using less than, greater than or
equal to conditions.

Some flags are free for you to have complete control
over, that is, any change to them must be made through
either the event or status table entries.  Some flags
have more specialised uses, for example, some count down
every time the player takes a turn, some count down only
if it is dark, and one stores the players current
location.  These special flags are listed in Appendix 1.


CONDITIONS IN THE EVENT AND STATUS TABLES.

Conditions in the status and event tables are satisfied
as follows:

ATGT lnumber.       Satisfied when the current location
                    number is greater than lnumber.

ATLT lnumber.       Satisfied when the current location
                    number is less than lnumber.

AT lnumber.         Satisfied if the current
                    location number is the same as
                    lnumber.

NOTAT lnumber.      Satisfied if the current location
                    number is not the same as lnumber.

PRESENT onumber.    Satisfied when object onumber is at
                    the current location.

ABSENT onumber.     Satisfied when the object
                    onumber is not at the current
                    location.

CARRIED onumber.    Satisfied when object onumber is
                    being carried.

NOTCARR onumber.    Satisfied when object onumber is not
                    carried.

WORN onumber.       Satisfied if object onumber is
                    currently worn.

NOTWORN onumber.    Satisfied if object onumber is not
                    worn.

CHANCE number.      Satisfied if number is less than a
                    computer generated pseudo-random
                    number between one and one hundred.

GT fnumber value.   Satisfied if the value of flag
                    fnumber is greater than value.

LT fnumber value.   Satisfied when the value of flag
                    fnumber is less than value.

EQ fnumber value.   Satisfied if the value of flag
                    fnumber is equal to value.

ZERO fnumber.       Satisfied if flag fnumber is equal to
                    zero.

NOTZERO fnumber.    Satisfied when flag fnumber has
                    any value other than zero.

Each of the conditions available in Advent are simple,
but by combining them in event and status table entries,
complicated systems can be developed, for example, the
entry:

ATGT 12 ATLT 32 EQ 45 12 EQ 377 12 GT 6 2 CARRIED 4
CARRIED 2 MESSAGE 3

will display the message only if the player is in a room
numbered between 13 and 31 inclusive, is carrying objects
two and four, flag 45 is equal to 12, flag 377 is equal
to twelve, and flag 6 has a value larger than two.  There
is no limit to the complexity of an entry other than the
length of the expression.


ACTIONS IN THE EVENT AND STATUS TABLES.

When the words and conditions of an event or status table
entry have been satisfied the actions are executed.  The
following actions are supported by Advent:

DESC.               A jump is made to the beginning
                    of the interpreter loop, table
                    processing is stopped and the current
                    location is described.

DONE.               This action is used to end
                    processing of the particular table in
                    which it is executed.  It is useful
                    if you want to prevent processing of
                    subsequent entries even though their
                    conditions may be satisfied.

OK.                 System message number 16 "OK." is
                    printed before action DONE is
                    performed.

MESSAGE mnumber.    The message mnumber is printed.

ANYKEY.             System message 17, prompting for a key to
                    be pressed is displayed at the bottom
                    of the screen.  Execution of the game
                    pauses until a key press is detected.

SAVE.               A filename is prompted for, and
                    the current game position is saved to
                    disk, allowing a complete return to
                    the game as it was left in a previous
                    playing session.

LOAD.               Loads a game position file as
                    created by the SAVE action.

INVEN.              The interpreter prints the system
                    message (10) "I have with me:" and
                    the object texts of the objects
                    carried are displayed below.  If an
                    item is being worn system message 11,
                    "(worn)" is printed after it.  If no
                    objects are being carried the system
                    message (12) "Nothing at all." is
                    displayed instead.  The action DONE
                    is performed, halting processing of
                    the current table.

PAUSE seconds.      The game pauses for the number
                    of seconds specified in seconds.

GOTO lnumber.       The players position is changed to
                    location lnumber.

TURNS.              This action displays the number of
                    turns taken by the player at this
                    stage of the game.  The message is
                    composed from system messages
                    numbered between 18 and 21.  "You
                    have taken n turns."  Where n is
                    calculated from the two flags which
                    store the turns counter (55 and 56).

SCORE.              The score, s, held in flag 54 is
                    displayed with the message "You have
                    scored s%" composed from system
                    messages 22 and 23.

REMOVE onumber.     If the player was wearing the
                    object it's position becomes CARRIED,
                    and flag 2, the number of objects
                    carried is increased by one.  If the
                    player is not wearing the object the
                    system message 24 "I am not wearing
                    it" is displayed and DONE is
                    performed.  If the maximum number of
                    objects is already being carried the
                    system message 25, "My hands are
                    full" is displayed, DONE is
                    performed, and the object is not
                    removed.

GET onumber.        If the object is already worn or
                    carried by the player system message
                    26 "I already have it." is displayed
                    before DONE is performed.  If the
                    object requested by onumber is not at
                    the current location, system message
                    27 is displayed, "It is not here,"
                    followed by action DONE.  If the
                    maximum number of objects is already
                    being carried, system message 28 "I
                    cant carry any more" is followed by
                    action DONE.  Otherwise the object is
                    picked up, ie, it's position is
                    updated to CARRIED, and flag 2 is
                    increased by one.

DROP onumber.       If the player doesn't have the object
                    system message 29 "I don't have it"
                    is displayed and action DONE is
                    performed.  If the object is being
                    worn, and the player is carrying the
                    maximum number of objects allowed,
                    system message 25 "My hands are full"
                    is followed by action DONE.  In any
                    other case, the object is placed at
                    the current location and flag 2 is
                    decreased by one if the object was
                    previously carried, rather than worn.

WEAR onumber.       If the object is already being worn,
                    system message 30 "I am already
                    wearing it" is followed by action
                    DONE.  If the object is not carried,
                    system message 29 "I do not have it"
                    is printed, and DONE is performed.
                    Otherwise, the position of the object
                    becomes WORN, and flag 2 is decreased
                    by one.

AUTOG.              The second word that was recognised
                    in the players input is searched for
                    in the object word table.  If it is
                    found, the object number of that
                    object is used to invoke the GET
                    action.  If a match is not found
                    system message 9 "I can't" is
                    displayed and action DONE is
                    performed.

AUTOD.              As for AUTOG, the object word table
                    is searched for an entry to match the
                    second recognised word in the players
                    input.  If one is found the object
                    number for that object is used to
                    invoke the DROP action.  If no match
                    is found system message "I can't" is
                    displayed and action DONE is
                    performed.

AUTOW.              If the second word in the players
                    input is not a word associated with a
                    wearable object, i.e. wordvalue < 21
                    or wordvalue > 99, the system message
                    9, "I can't" is displayed and the
                    DONE action is executed.  If the word
                    refers to a wearable object the
                    object word table is searched for a
                    matching entry.  If no match can be
                    found, system message 9 is displayed,
                    and action DONE is executed.
                    Otherwise, the appropriate object
                    number is passed to the WEAR action.

AUTOR.              If the second word in the players
                    input does not refer to a wearable
                    object, then system message 9, "I
                    can't" is displayed and action DONE
                    is performed.  If the word refers to
                    a wearable object, the object word
                    table is searched for a matching
                    entry.  If no match is found system
                    message 9 is displayed and action
                    DONE is executed.  Otherwise, the
                    appropriate word number is passed to
                    the REMOVE action.

DESTROY onumber.    The position of object onumber is
                    changed to NOT CREATED and flag 2 is
                    reduced by one if the object was
                    carried by the player.

CREATE onumber.     The position of object onumber
                    is changed to the current location.
                    If the object was carried it is
                    dropped, and flag 2 is decremented if
                    this was the case.  An object that
                    has been DESTROYed can always be
                    recreated with CREATE.

SWAP onumber1 onumber2.
                    The positions of the two objects are
                    swapped.

SET fnumber.        Flag fnumber has it's value set to
                    32767.

CLEAR fnumber.      Flag fnumber is reset to zero.

PLUS fnumber value. Value is added to the number stored
                    in flag fnumber and the result is
                    stored in the same flag.  If the
                    result is a number larger than 32767,
                    the number 32767 is stored instead.

MINUS fnumber value.Value is subtracted from the
                    number stored in flag fnumber, and
                    the result is stored in the same
                    flag.  If the result is a negative
                    number, the value zero is stored
                    instead.

LET fnumber value.  The number stored in flag fnumber is
                    set to value.

BEEP duration, pitch A tone is produced by the
                    computers loudspeaker.  Duration is
                    measured in 100ths of a second, and
                    frequency is measured in Hertz.

CLS.                The screen is cleared to black.

DROPALL.            Any objects which the player is
                    carrying or wearing are dropped at
                    the current location, flag 2 is set
                    to zero.

PLACE onumber lnumber.
                    The position of object onumber is
                    changed to location lnumber.  If the
                    player was carrying or wearing the
                    object, flag 2 is decremented.

QUIT.               "Are you sure you want to quit?"
                    (System message 13) is displayed and
                    the player has to reply.  The first
                    letter of the reply is tested against
                    the first letter of system message
                    number 31.  If the letters are the
                    same processing of the conditions
                    continues, otherwise DONE is
                    performed to finish processing the
                    current table.  The system messages
                    31 and 32 are never displayed but
                    store affirmative and negative
                    responses.  They will typically be
                    "Y" and "N", but can be changed,
                    perhaps to a foreign language.  For
                    example if the rest of the game is
                    written in French, the user might be
                    expected to answer "O" for the
                    affirmative rather than "Y", in which
                    case these messages would store "O"
                    and "N" respectively.

END.                This is the `way out' of the game.
                    The system message 14, "Do you want
                    to try again?" is printed and the
                    players response is processed as
                    described for QUIT.  If the answer is
                    negative the processing jumps to DOS,
                    (or the Advent main menu, if you are
                    in TEST ADVENTURE mode).  Otherwise
                    (affirmative response) the game
                    begins again.


A DESCRIPTION OF THE INTERPRETER.

This section describes how the program PLAYA.EXE uses
your data to play a game.

This description is given in sufficient detail to allow
game writers to get the most from Advent.
The interpreter can be considered as a large loop, a
repeating sequence of events as described below.
The interpreter begins by describing a
location, and this can be considered the beginning of the
loop.

The description of the location that the player is
currently at is displayed on the screen.  The flags are
adjusted, i.e. they are incremented or decremented as
described elsewhere.
The system message (2) "I can see" is displayed and the
objects at that location are described with their object
texts.  If there are no objects present then the system
message is not displayed.
If it is dark (flag 1 is not zero) and object 1 is not
present, the location and object texts are not displayed,
and the system message (1) "It is dark, I cannot see." is
printed instead.  Note that object 1 is considered a
source of light.

The interpreter then begins processing the status table.
The first entry is taken and its conditions tested.  If
the conditions are met then the associated actions will
be performed.  If the conditions are not met, or when the
actions have been performed, the next entry is
considered.  This continues until every entry has been
tested.
Exceptions to this are when an action DESC is
encountered, when the interpreter jumps back to the
beginning of its loop, or when DONE is encountered, when
no more status entries are considered.

Next the player is asked for an entry, with one of the
system messages (3, 4, 5 or 6) randomly chosen for use as
a prompt.  The flags are processed again at this time, as
described elsewhere.  The player then enters their
command.

The interpreter searches the vocabulary for the words in
the players command.  The first two words in the players
entry which can be matched with words in the vocabulary
are stored, and processing continues.
For example, the entry, GET THE HAT would be stored as
GET HAT, provided that the word THE is not in the
vocabulary whilst GET and HAT are.  Supposing that the
word THE was also found in the vocabulary, the entry GET
THE HAT will be interpreted as GET THE, from which very
little meaning can be extracted.  It is up to the game's
author to include whatever words they like in the
vocabulary, and situations such as the above can be
avoided by careful planning.  Usually `little' words like
THE, GO and ON are not included.

If the entry is not found, and the entry is not
recognised as a valid `HASH STRING' then the interpreter
displays the system message (7) "I don't understand."
Hash strings are described in Part 2 of this manual,
under the sub heading 'Hash Strings.'

When an entry is found the movement table is consulted.
If the first recognised word is defined as a movement
word for the current location, the player is moved to the
appropriate place, and the interpreter jumps to the
location description.  The movement table is not
consulted if the command has already been identified as a
hash string.

If not found in the movement table the entry is passed to
the EVENT table.  This process is similar to the status
table search, but in addition to the matching of
conditions, the players entry must also match the `Event
words' or hash string associated with a particular entry
before its actions will be executed.  If matched
correctly the actions for that entry are performed, with
DESC and DONE having identical effect to that in the
status table.  Notice also that some other actions may
cause the interpreter to end event or status table
processing, as described in Part 3 of this manual under
'Actions in the Event and Status Tables.
If the players entry cannot be matched the system message
(9) "I can't go in that direction." is displayed if the
first word was a movement word.  System message (10) "I
can't." is displayed if the word was not a movement word.

The interpreter then returns to the beginning of its loop
(location description).


OTHER PROGRAMS SUPPLIED WITH ADVENT:  ADVPACK AND ADVLOCK

USING ADVPACK.

The Advent database editor makes 'intelligent' use of the
space in the data file by keeping track of spare space,
and using that spare space when it can, rather than
increasing the size of the file.  This process is still
not however, 100% efficient, and it is not unusual for
small spaces to be left in the data file.

It is also true that the data in the data file is not
carefully structured.  The entries from the event table
are not necessarily all stored sequentially, for example.
Advent is able to cope with this 'disorder' by use of the
index file, which, just like the index in a book, enables
items to be found extremely rapidly.

The interpreter would be able to work even faster if
tables such as the event and status tables were stored
sequentially in the data file.  Disk buffering and
caching systems would also become more effective...

ADVPACK.EXE can help in both cases.  It packs the data
into the smallest possible space by removing redundant
space, and orders entries sequentially for the fastest
possible access.  It does this without compressing the
actual data, so it is still possible to edit your game
using the Advent database editor.

When should you use ADVPACK?

Advpack would normally be used when your game is
complete.  This would ensure that the final version was
as space and speed efficient as possible.  You may also
wish to use Advpack occasionally during the development
of a large game, to keep the size of the database down,
and to maintain the efficiency of the intelligent
indexing system.

Remember to ADVPACK your game when it is complete no
matter how many times it has been done during
development.


RUNNING ADVPACK.

Before running ADVPACK it is sensible to make a backup of
your data (.DAT) AND index (.IDX) files, just in case
something goes wrong.  You should make sure that there is
free space equal to or greater than the length of your
data file in the same directory as your index and data
files.  Advpack will need to create a temporary file.

Type ADVPACK at the DOS command line to invoke the
ADVPACK.EXE program.  You will be prompted to enter the
filename of the game to be packed.  You may enter a drive
and path specification, but should not enter any file type
extension as Advpack adds its own.

If the files are found, and there is enough free space,
Advpack will go to work.  It indicates on screen the
blocks of data that it is moving, before finally updating
the index file.

At the end of the operation the number of bytes saved are
displayed, and you are returned to DOS.


USING ADVLOCK.

Suppose that you have finished a game and wish to
distribute it.  Another user of the Advent system could
load your game into their editor, and make unauthorised
changes, or steal your ideas, or simply cheat in order to
complete the game.

Advlock enables the data and index files to be 'locked'
so that the Advent editor will refuse to load them.  The
game can still be played using PLAYA.EXE as normal.

Using ADVLOCK to lock or unlock a file.

Type ADVLOCK at the DOS command line to load the program
ADVLOCK.EXE.  You will be prompted to enter the filename
of the game that you wish to lock or unlock.  You may
give a drive or path specification but should not add a
file type extension, as Advlock add these automatically.

If the game specified is currently unlocked you will be
told this and asked to enter a password.  Type carefully,
and press return to lock the file.  The password that you
entered will be encrypted into the files, and Advent will
refuse to allow them to be edited.

If the game that you specified is currently locked, you
will be asked to enter the same password that was used to
lock the files.  Only if you enter the same password will
the files be unlocked to allow editing.

When all operations have been completed you will be
returned to DOS.


NOTE AND DISCLAIMER:

Whilst ADVLOCK provides some protection against
unauthorised changes to your files, it should not be
considered effective against the determined hacker!  It
would be sensible to apply the normal Copyright
protection to any game that you wish to distribute.

I can accept no responsibility for the effectiveness or
ineffectiveness of the ADVLOCK system to protect your
files.  Having said that, it would be asking for trouble
if you were to distribute a game that had not had ADVLOCK
protection applied.



APPENDICES


APPENDIX 1.
FLAG LIST:

Flag number.   Description.
1.             Non zero if it is dark.  Zero if light.
2.             Number of objects carried.
3 - 13.        Decreased when a location is described.
14 - 23.       Decreased when a location is described and
               it is dark.
24 - 33.       Decreased when a location is described, it
               is dark, and object 1 is absent.
34 - 44.       Decreased each turn if it is dark.
44 - 53.       Decreased each turn if it is dark and
               object 1 is absent.
54.            The player's score.
55/56.         Number of turns taken is given by
               (32768 * Flag 56) + Flag 55.
57 - 150.      Decreased each turn.
151 - 400.     Ordinary flags.


APPENDIX 2.
SUMMARY OF CONDITIONS:

ATGT lnumber.
ATLT lnumber.
AT lnumber.
NOTAT lnumber.
PRESENT onumber.
ABSENT onumber.
CARRIED onumber.
NOTCARR onumber.
WORN onumber.
NOTWORN onumber.
CHANCE number.
GT fnumber value.
LT fnumber value.
EQ fnumber value.
ZERO fnumber.
NOTZERO fnumber.


APPENDIX 3.
SUMMARY OF ACTIONS:

DESC.
DONE.
OK.
MESSAGE mnumber.
ANYKEY.
SAVE.
LOAD.
INVEN.
PAUSE seconds.
GOTO lnumber.
TURNS.
SCORE.
REMOVE onumber.
GET onumber.
DROP onumber.
WEAR onumber.
AUTOG.
AUTOD.
AUTOW.
AUTOR.
DESTROY onumber.
CREATE onumber.
SWAP onumber1 onumber2.
SET fnumber.
CLEAR fnumber.
PLUS fnumber value.
MINUS fnumber value.
LET fnumber value.
BEEP duration, pitch
CLS.
DROPALL.
PLACE onumber lnumber.
QUIT.
END.


APPENDIX 4.
ADVENT DATA FILES.

Advent stores the information required for the adventure
game in two disk files.  One of these, with the .DAT
suffix contains the data for the adventure.  The .DAT
file holds data with no definite structure, so in order
that the program knows where to find the information it
needs, the .IDX file holds a complete index to the data
file.  The .IDX file is highly structured, allowing
advent to find the data it needs with the minimum delay.
So that players cannot cheat, the data file is coded to
make it unreadable when loaded into an editor or file
viewer.

The INDEXED DATA FILE system used by Advent allows the
interpreter to find the data it needs in the shortest
possible time.  On loading an adventure the indexes are
copied into memory to further speed access.  The
vocabulary is also stored in the index file, as the
computer needs to access it frequently.  Data can be read
much more rapidly from memory than it can from disk.

The index file has a fixed length of just over 60000
bytes.  The data file however is just large enough to
hold the data it contains, and grows accordingly.  Advent
manages the space in the data file intelligently and
keeps a record of unused space, which it tries to fill as
best it can.  the details of a number of such spaces are
remembered, however small gaps in the data file may be
ignored or forgotten about, and the utility ADVPACK is
provided on the Utilities Disk to compress completed data
files.


APPENDIX 5.
DISTRIBUTING YOUR COMPLETED GAME.

When your game is complete, and you have checked it
carefully, you may wish to distribute it.  Please be sure
that you are a registered Advent user before distributing
your game.
Remember that you should include a copy of the PLAYA.EXE
program with the data files that you distribute.
PLAYA.EXE is Public Domain software as described at the
beginning of this document.

The game is then run by typing:

PLAYA GAMENAME

at the DOS command line.

It might be more desirable to begin the game by typing
its name.  This can be done by executing PLAYA GAMENAME
from within a batch file or a small .COM program.

Supposing the game was called Treasure Hunt, and the
filename of the data and index files was THUNT, a
suitable batch file might be created with:

COPY CON TREASURE.BAT
ECHO OFF
PLAYA THUNT
[CTRL-Z]

Which would create the batch file TREASURE.BAT.  The game
could then be run by typing TREASURE at the DOS prompt.

Any charge that you make for the games you create is left
to your discretion, but please remember that you are
charging for the parts of the game that you yourself
created.  You must make no charge for PLAYA.EXE.
Please note that all files created with ADVENT are marked
as such, and will be rendered useless by removal of these
identification marks.